• evmrpc/request_limiter.go#L159-L169

The bug. Before this PR, requestSizeLimiter.ServeHTTP released the global byte-budget semaphore with defer l.budget.Release(weight), so the reservation was returned even if the inner handler panicked. This PR replaces incremental up-front reservation with per-chunk charging via budgetBody, and moves the release to plain sequential code in request_limiter.go:88-99:

l.inner.ServeHTTP(cw, r)

if budgetWrapped != nil {
    _ = budgetWrapped.Close()
    budgetWrapped.release()
}

There is no defer and no recover around these two calls. If l.inner.ServeHTTP panics, both Close() and release() are skipped entirely, and the panic unwinds straight past this frame.

Why the panic can actually reach here. The pinned go-ethereum fork's RPC server only recovers panics inside the per-method callback (rpc/service.go, callback.call) — that is, only once a JSON-RPC method handler is actually invoked. Everything upstream of that in the chain this PR wires — seiLegacyHTTPGate (which does its own io.ReadAll plus JSON batch-parsing/merging with slice/map indexing such as entries[idx]/used[idx], with no recover of its own), the gzip/vhost/cors middleware, and rpc.Server's own HTTP dispatch/decode path, are not covered by that recover. A panic anywhere in that surface propagates directly through requestSizeLimiter.ServeHTTP, which also has no recover, up to net/http's per-connection recover — the process survives, but the connection-level recover has no knowledge of the semaphore, so the reservation is never returned.

Why the leak is material, not just theoretical. seiLegacyHTTPGate buffers the whole body via io.ReadAll before it starts its batch-merge logic. budgetBody.Read flushes all unbilled bytes into the semaphore (b.reserved) on EOF, so by the time the gate's merge logic (or anything after the body read) runs, the full body's worth of bytes — up to maxBody (5 MiB by default) — is already charged to the process-global max_concurrent_request_bytes semaphore (128 MiB by default). A single panic there leaks up to 5 MiB; roughly 25 such panics would exhaust the entire budget, after which every legitimate request gets rejected with HTTP 429 until the process restarts. This is a persistent, resource-exhaustion DoS — notably the exact failure class this PR's own description says it is closing (the slowloris/budget-exhaustion gap).

Step-by-step proof:

1. Client sends a JSON-RPC batch request containing a gated sei_* method plus a malformed entry designed to trigger a panic in seiLegacyHTTPGate's merge logic (e.g. an out-of-range index reachable through its entries[idx]/used[idx] bookkeeping) — or any other panic reachable in the gzip/vhost/cors/dispatch layers.
2. requestSizeLimiter.ServeHTTP wraps r.Body in budgetBody, which charges bytes to l.budget (the shared semaphore) as the gate reads the body via io.ReadAll, and flushes the remainder into b.reserved on EOF — up to the full body size.
3. l.inner.ServeHTTP(cw, r) is called, which invokes the gate; the gate's merge logic panics.
4. The panic unwinds through requestSizeLimiter.ServeHTTP without executing budgetWrapped.Close()/release(), because there is no defer.
5. The panic is finally caught by net/http's connection-level recover; the connection is dropped, but l.budget's Weighted semaphore still shows the bytes from step 2 as acquired — permanently, for the life of the process.
6. Repeating steps 1-5 ~25 times (5 MiB each against a 128 MiB budget) exhausts max_concurrent_request_bytes entirely; all subsequent legitimate JSON-RPC requests are rejected with HTTP 429 until the node operator restarts the process.

Why nothing else prevents this. budgetBody.fail() handles the ordinary error paths (budget exhaustion mid-read, idle timeout) by calling b.release() itself, but that only covers errors returned from Read() — not a panic thrown by code that has already consumed the body downstream. The per-method recover() wrappers used elsewhere in evmrpc/*.go (e.g. in tracers.go, send.go, block.go) only protect the individual RPC method being called; they don't run for panics in the HTTP-layer plumbing this PR touches.

The fix is exactly what the old code already did: wrap the cleanup in a defer so the budget is released unconditionally, regardless of whether l.inner.ServeHTTP returns normally or panics, e.g. defer func() { _ = budgetWrapped.Close(); budgetWrapped.release() }() placed immediately after budgetWrapped is constructed.

What the bug is. In budgetBody.Read (evmrpc/request_limiter.go), the idle-deadline guard is:

if b.idleTimeout > 0 && b.rc != nil {
    if err := b.rc.SetReadDeadline(time.Now().Add(b.idleTimeout)); err != nil {
        // ResponseController may be unavailable on exotic ResponseWriters; proceed
        // without the idle guard rather than failing the request.
    }
}

The inner if err != nil { ... } branch contains nothing but a comment. staticcheck's SA9003 rule treats a comment as a non-statement, so from the analyzer's point of view this branch is empty — a classic "did you forget to handle this error" pattern, and the check fires regardless of the intent conveyed in the comment.

How it manifests / proof. I reproduced this directly against the repo's own toolchain:

$ golangci-lint --version
golangci-lint has version 2.5.0 built with go1.25.1 ...
$ golangci-lint run --enable-only=staticcheck ./evmrpc/
evmrpc/request_limiter.go:128:3: SA9003: empty branch (staticcheck)
                if err := b.rc.SetReadDeadline(time.Now().Add(b.idleTimeout)); err != nil {
                ^
1 issues:
* staticcheck: 1

This is the exact line the PR adds as part of the new budgetBody type backing the streamed body-budget charging feature.

Why nothing else in the repo prevents it. .golangci.yml sets default: none and then explicitly re-enables staticcheck in linters.enable, with no per-check staticcheck.checks override that would disable SA9003, and no path-based exclusion covering request_limiter.go (only generated *.pb.go files and one gosec weak-RNG rule are excluded). request_limiter.go is ordinary non-test source, so run.tests: false in the config doesn't exempt it. AGENTS.md/CLAUDE.md state that make lint (which runs golangci-lint per .golangci.yml) must be clean, and .github/workflows/golangci.yml runs the same golangci-lint version in CI. So this is a genuine, reproducible CI-blocking failure introduced by this PR, not a style nit that a reviewer could wave through.

Impact. As committed, make lint fails locally and the golangci-lint GitHub Actions check fails on the PR, blocking merge until fixed. It's purely a lint/CI-gate issue — there's no runtime behavior bug here (the surrounding comment's stated intent, "proceed without the idle guard rather than failing the request," is a reasonable behavior and doesn't need to change).

Fix. Give the branch a real no-op statement instead of only a comment, e.g.:

if err := b.rc.SetReadDeadline(time.Now().Add(b.idleTimeout)); err != nil {
    logger.Debug("SetReadDeadline unavailable for body read idle timeout", "err", err)
}

or equivalent (_ = err plus a comment, or restructuring to drop the nested if entirely). Either resolves SA9003 while preserving the existing fallback behavior.

budgetBody.Read (evmrpc/request_limiter.go:126-133) calls rc.SetReadDeadline(time.Now().Add(idleTimeout)) unconditionally on every single Read invocation whenever bodyReadIdleTimeout > 0 — which it is by default (BodyReadIdleTimeout: 10 * time.Second in config.go). http.ResponseController.SetReadDeadline is not a separate, layered "idle" deadline; per the Go 1.25.6 net/http source (server.go:499-500), (*response).SetReadDeadline calls c.conn.rwc.SetReadDeadline directly — the exact same socket-level deadline that net/http's readRequest arms once, after headers are parsed, to wholeReqDeadline = t0.Add(Server.ReadTimeout) (server.go:1018-1086). That absolute deadline exists specifically to bound "the maximum duration for reading the entire request, including the body" (the documented semantics of ReadTimeout, echoed in this repo's own evmrpc/config/config.go doc-comment).

Because every chunk read re-arms the deadline to now + idleTimeout instead of computing min(now+idleTimeout, wholeReqDeadline), a client that sends any nonzero amount of body data at an interval shorter than body_read_idle_timeout (e.g. 1 byte every 9 seconds, since the default idle timeout is 10s) keeps pushing the deadline forward indefinitely. Neither guard ever fires: the idle timeout never sees a >10s gap, and the absolute 30s ReadTimeout it silently overwrote can never trip because it no longer exists on the socket. The read is then bounded only by MaxBytesReader's total byte cap (5 MiB by default), which at a 1-byte/9s trickle is on the order of hundreds of days of wall-clock time — effectively unbounded. For that entire duration the connection, its serving goroutine, and one of the max_open_connections slots (default 2000) are pinned.

This is a straightforward regression in the exact direction opposite to what the PR sets out to fix: PLT-780 closed a slowloris gap where a stalled body could pin a large byte-budget reservation cheaply. This change reintroduces a connection/goroutine-lifetime slowloris vector — one that the pre-existing ReadTimeout used to close at a hard 30s ceiling for the body-read phase, and which is now open again, active by default, even in configurations where the byte budget itself is disabled (the wrapping only requires bodyReadIdleTimeout > 0, independent of budget != nil). There is no other mitigation in the stack: per-IP rate limiting isn't wired into this HTTP middleware chain, and even if it were, a rate limiter bounds request arrival rate, not the lifetime of a single already-admitted connection.

The PR's own new tests do not catch this because they build their servers with httptest.NewServer, which never sets http.Server.ReadTimeout. With no absolute deadline present in the test harness, there is nothing for the per-chunk reset to clobber, so TestRequestSizeLimiter_bodyReadIdleTimeout and TestRequestSizeLimiter_steadySlowUploadSucceeds both pass despite the regression. In production, rpcstack.go's Start() always sets http.Server{ReadTimeout: h.timeouts.ReadTimeout}, and CheckTimeouts (evmrpc/endpoints.go) guarantees that value is never below 1s, sanitizing it up to the 30s go-ethereum default when unset — so the absolute deadline is always present in the real server.

Proof walkthrough:

1. Server starts with ReadTimeout = 30s (default) and BodyReadIdleTimeout = 10s (default).
2. A malicious client opens a POST with Content-Length: 5000000 (near the 5 MiB cap) and sends only 1 byte, then goes idle for 9 seconds, then sends 1 more byte, repeating indefinitely.
3. At t=0, after headers are read, net/http arms wholeReqDeadline = t0 + 30s on the socket.
4. At t≈0, requestSizeLimiter wraps the body in budgetBody; the inner handler calls Read, which first calls rc.SetReadDeadline(now + 10s) — overwriting the socket deadline from t0+30s down to t0+10s (this alone already shortens the "whole request" cap, but at least still bounds it).
5. At t≈9s, the 1-byte chunk arrives, Read returns 1 byte, and the next Read call immediately resets the deadline to t≈9s + 10s = t≈19s.
6. This repeats every ~9s forever: t=9s → deadline 19s, t=18s → deadline 28s, t=27s → deadline 37s (already past the original 30s absolute cutoff, which no longer exists), and so on without bound.
7. The connection survives past the documented 30s ReadTimeout and continues indefinitely, limited only by the ~5 MiB MaxBytesReader cap — at 1 byte/9s that is roughly 5×10^6 × 9s ≈ 1.4 years of wall-clock time to exhaust, i.e., practically unbounded for operational purposes.

Fix: compute the idle deadline as min(now+idleTimeout, wholeReqDeadline) rather than unconditionally overwriting the socket deadline forward. Since wholeReqDeadline isn't directly exposed via ResponseController, an equivalent fix is to track an absolute deadline computed once when the wrapped body is constructed (readStart + ReadTimeout, threaded in from config) and cap each per-chunk SetReadDeadline call at min(now+idleTimeout, absoluteDeadline).